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BUSINESS OPTIMISATION 

The present invention relates to a method of designing 
or optimizing a business. 
5 Conventionally, business organisation has been carried 

out on a manual basis with the result that there is often 
duplication of tasks within different areas of the business 
while improvements in business processes which are applied 
in one area are not applied to other areas because there is 

10 no recognition that they are equally applicable. Worse 
still, they may not be applicable because the business has 
grown without any consistency or uniformity. 

In accordance with a first aspect of the present 
invention, we provide a method of designing or optimizing 

15 a business, the method comprising defining the business as 
a number of business process objects and their interactions 
using object orientated design techniques, each business 
process object being designed to provide one or more 
services in response to an event. 

2 0 Accordingly, we provide a method which utilises object 

orientated techniques to design or modify a business. The 
invention operates by defining the business as a number of 
interacting business process objects. The business process 
objects can then be modelled from scratch or from 

25 predetermined business process objects using object 
orientated design techniques. 

Object orientated techniques involve considering 
systems in general terms to allow similarities between 
apparently different processes and systems to be 

30 established. Such techniques are currently used in 
software design by considering the relationship between 
different problems and solutions. Once a relationship is 
determined, this can be used for adapting software fc_ use 
in a number of different systems. 

35 This technique therefore allows improvements to be 

propagated between business process objects so as to 
improve the overall efficiency of the business as well as 
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allowing the business to be defined in a manner which 
allows easy implementation and modification as required. 
General object orientated methods are described in "Object 
Orientated Methods A Foundation" by James Martin and James 
5 J Odell. 

Furthermore, the alteration of the operation of one 
business process object can cause subsequent alteration of 
the operation of other business objects within the system, 
thereby allowing alterations to easily propagate through 

10 the business ensuring efficient adaptation of the business 
to different circumstances. 

The method typically involves defining the business as 
a number of interacting statecharts, each statechart 
representing a number of states of business processes or 

15 sub-processes. 

The method preferably comprises defining the business 
as a number of statecharts, each statechart representing a 
number of states of the business, the states being 
interconnected by events and corresponding event response 

2 0 actions, each state corresponding to a respective business 
process object and each event response action corresponding 
to a service provided by the respective business process 
object in response to an event. 

The term statechart as used in the invention refers to 

25 any definition of a number of interacting states and is not 
limited to graphical representation. This term should 
therefore be used interchangeably with the term 
statemachine. The statechart diagrams are merely graphical 
representations of the underlying information defined by 

30 the statecharts themselves. 

Details of how the predetermined business process 
objects operate are defined in statecharts. Each 
statechart sets out how different states of a business 
process object interact to allow the business process 

35 object to function. This therefore allows the services 
which the business process object defines to be implemented 
more readily. 
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The method normally requires the determination of 
service implementations of at least some of the event 
response actions, the service implementation defining the 
procedures required for implementing the respective event 
5 response action- This allows various aspects of the 
operation of the business process objects to be defined 
relatively easily. In particular, the implementation of a 
given business process object may vary depending on the 
circumstances in which it is used (known as a 

10 polymorphism).. However, this can readily accounted for 
simply by using appropriate service implementations and 
statecharts depending on the circumstances in which the 
business process object is used. 

Typically the method further comprises defining at 

15 least some of the business process objects as respective 
statecharts so as to generate a hierarchical structure of 
statecharts. By defining a hierarchical structure, it is 
possible to identify any services which must be adapted, 
with greater precision. Furthermore, it will be 

20 appreciated that in many circumstances the higher level 
statecharts themselves do not require any modification per 
se, although the event response actions of the states may 
turn out to be incorrect. 

In this case the original statecharts are satisfactory 

25 and do not require modification. However, the step of 
analysing the sub-level statechart is still useful as it 
may allow the event response action to be corrected at a 
more detailed level of design. . Furthermore, the business 
can be modified on different levels without effecting the 

30 operation of other levels of the. business. This is 
particularly advantageous if it is required, for example, 
to modify the way in which one particular business process 
object operates when this should not affect the operation 
of any other business process object. 

35 As will be appreciated, the provision of the 

hierarchical structure therefore allows different aspects 
of the business to be modified and optimized as required 
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with the effects of this being propagated through the 
business without necessarily requiring modification of the 
business model as a whole. 

Typically the method of determining a statechart of a 
5 business process object comprises the steps of: 

a. comparing the business process object to a number 
of predetermined business process objects; 

b. determining if one of the predetermined business 
process objects can be related to the business 

10 process object by an object-oriented process; and, 

either : 

i. using a predetermined statechart of a 
predetermined business process object that is 
related to the business process object; or, 

15 ii. generating a new statechart. 

This allows statecharts which have already been 
determined for alternative business process objects to be 
readily utilized when designing or modifying a business. It 
is also possible to generate the statechart from a 

20 consideration of the services and capabilities which the 
business process object must achieve. However, by modifying 
existing statecharts, any improvements to the statechart can 
then be incorporated back into the original predetermined 
business • process object. This not only results in 

25 modifications being propagated throughout the business design 
thereby allowing enhanced operation of a greater proportion 
of the business but also this allows modification of the 
predetermined database so that improvements can also be 
automatically implemented within other businesses. 

30 The predetermined business process object can be a 

generalization or a specialization of the business process 
object. Alternatively, identical business process objects may 
be used. 

The method of generating a new statechart usually 
35 involves: 

a. determining events to which the business process 
object must respond; 
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b. dividing the events into sets of related events, 
each set of related events being associated with 
a respective state of the business; 

c. for each event, defining one or more event 
5 response actions for providing the required 

services. 

This advantageously ensures that each state is 
associated with a set of related events to ensure that states 
are independent of each other. However, states are then able 
10 to interact with each other should this become necessary. 

The method generally further comprises incorporating the 
generated statechart and the associated business process 
objects into the model of ..the business. As this occurs, it 
may become readily apparent that there are inconsistencies in 
15 the current business model in which case the model can be 
adapted as required. 

The method of using the predetermined statechart 
comprises : 

a. . comparing the services provided by - the 
20 predetermined business process object with the 

services to be provided by the business process 
object; and, 

b. if necessary, modifying the selected statechart by 
performing at least one of the following steps: 

25 i. adding in one or more new states, and 

interconnecting the new states to existing 
states using appropriate event response 
actions so as to provide the required 
services; or, 

30 ii. modifying the event response actions of 

existing states to represent changes in the 
services to be provided by the business 
process object. 
This therefore provides techniques for modifying the 
35 statecharts of the predetermined business process objects if 
they do not accurately model the business process object 
under consideration. A further alteration that is possible 
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is the modification of the way in which states interact, even 
if the states themselves do not need to be altered. 

The step of modifying the event response actions of an 
existing state can comprise modifying the service 
5 implementation of the event response action such that the 
state provides the required services. However, the 
alteration nay alternatively require the modification of 
deeper level statecharts. 

In this case, if the service implementation of the event 
10 response action cannot be modified, the method further 
comprises : 

(1) considering the business process object of the state to 
be modified; 

(2) determining a second level statechart of the business 
15 process object of the state to be modified; 

(3) determining the states of the second level statechart 
diagram which are to be modified; 

(4) for any states for which the service implementation 
cannot be altered to provide the required services, 

20 repeating steps (1), (2) and (3) to generate the nth 

level statechart diagram for which the service 
implementation of the state can be altered to provide 
the required services; and, 

(5) modifying the service implementation of the event 
25 response actions of the states of the nth level 

statechart such that the modified statechart represents 
the services provided by the respective business process 
object • 

By performing this repeated analysis of sub- levels of 
30 statecharts, it is possible to identify any services which 
must be adapted, with greater precision. Furthermore , it 
will be appreciated that in many circumstances the 
statecharts themselves do not require any modification but 
rather the event response action of the statechart may turn* 
35 out to be a polymorphic operation of the event response 
action of the statechart of a predetermined business process 
object. In this case the original statecharts are 
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satisfactory and do not require modification. However, the 
step of analysing the sub-level statechart is still useful as 
it allows the event response action which is polymorphic 
between the statechart s to be determined. 
5 Typically an nth level statechart diagram is determined 

from a number of predetermined statechart diagrams in 
accordance with the n-lth statechart. Again however the 
state chart may be determined by analysing the services and 
capabilities of the business process object and of the n-lth 
10 statechart. 

The method preferably further comprises: 

a. considering the modified statechart and the 
predetermined statechart; 

b. considering the effect of inheritance on the 
15 operation of the business process object as 

defined by the modified statechart and the 
predetermined business process object; and, 

c. adapting the relationship between the business 
process object and the predetermined business 

20 process object as required. 

Thus, for example, it may be decided that using a 
specialisation of the predetermined business process object 
is unsuitable due to the fact that any changes made to the 
predetermined business process object during operation of the 

25 business would then be inherited by the business process 
object. In this case it may be better to produce a more 
generalised predetermined business process object and then 
specialise that to form the business process object which is 
desired. Accordingly, constant consideration of the 

30 interaction between the statecharts and the business process 
objects can lead to revisions in the business model which 
then leads to further improvements in the operation of the 
business. This technique also has the advantages that 
alterations can be back propagated to the database of 

35 predetermined business process objects thereby allowing 
improvement of other businesses as well as the current 
business under consideration. 
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The service implementation may define one or more 
algorithms configured to perform at least a portion of the 
respective event response action. Alternatively, the service 
implementation defines one or more sets of instructions 
5 indicating the tasks to be performed in order to perform at 
least a portion of the respective event response action. 
Alternatively, as will be appreciated by a person skilled in 
the art, the service implementation may constitute a 
combination of instruction procedures to personnel of the 

10 business, as well as algorithms which are operated by 
processing systems to generate certain data. Alternatively 
the service implementation may be out sourced to a different 
company depending on the circumstances in which it occurs. 
In this case, the service implementation would simply be to 

15 obtain information, and/or goods or services from an external 
source . 

It will also be realised that the service 
implementations may be defined from scratch by considering 
the nature of . the service and considering the best way in 
20 which this could be provided in accordance with the current 
business object under consideration. Alternatively however, 
the method preferably further comprises determining the 
service implementation diagrams for a given event response 
action of a state by: 
25 a. comparing the business process object associated 

with the state to a predetermined business process 
object; 

b. determining a service implementation for an event 
response action of the state of the predetermined 

30 business process object; and, 

c. modifying the service implementation to allow the 
required event response action to be implemented. 

This has the advantage that it allows service 
implementation procedures which are known to work to be 
35 implemented within the business thereby ensuring that the 
service will be provided as requested. 
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The method can further comprise determining the core 
capabilities of a state of the business, the core 
capabilities representing the business process objects and 
their respective interactions required for the state to be 
5 implemented. This is a useful conceptual view of the 
business which allows the technique user to have confidence 
that the designed system is meaningful and functional. 
In this case, the method usually also involves: 

a. comparing the core capabilities with a number of 
10 predetermined core capabilities for different 

business states corresponding to the predetermined 
business process objects; and, 

b. modifying the core capabilities and the 
statecharts in accordance with the predetermined 

15 core capabilities. 

The obtained core capabilities diagrams can then be 
compared with the statechart to check that the business 
defined by the statechart is a reasonable business model. 

The method typically involves generating statechart 

20 diagrams representing the states, the event response actions 
and the event for a given statechart. Core capabilities 
diagrams showing the business process objects and their 
respective interactions which represent the core capabilities 
of any state of the business are also usually generated. The 

25 production of the diagrams allows the business manager to 
visualize how the generated business model will function in 
reality. In particular, it allows the business manager to 
examine statecharts and core capability diagrams at different 
levels within the business to obtain an idea of how the 

30 business process objects, and the various states of the 
business are interacting. 

The object orientated processes usually include the use 
of inheritance and polymorphism. 

The method may also further involve, presenting business 

35 data by associating business data with the statecharts and/or 
the core capabilities. This allows the data to be viewed on 
the appropriate statechart and/or core capabilities 
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representation making it easier for the business manager to 
determine the relevance of the data to the business model. 

It will be realized that the use of the above described 
techniques in combination, and notably the use of 
5 inheritance, statecharts and polymorphism, provides 
significant benefits over previous business modeling 
techniques. This is because of the inherent interaction 
between the techniques which allows the business to be more 
easily modeled. 

10 A further problem that has arisen in previous 

consideration of businesses is the calculation of the risk 
associated with the business failing to operate correctly. 
The risk of a business failing is a value required by law for 
many industries but this value is currently calculated on the 

15 basis of the size of the business and the income of the 
business. The value is actually determined using the 
equation: 

Risk = aA + PB (1) 



where: a = size coefficient 

A = size of the business 

3 « income coefficient 

B = income of the business 



25 Although the value of the coefficients can be altered, 

this technique has the particular disadvantage that large 
firms with a high income tend to have a high risk value even 
if the company itself is not particularly risky. 

In accordance with a second aspect of the present 
30 invention, we provide a method of risk assessment within a 
business, the method comprising the steps of: 

a. defining the business as a number of business 
process objects and their associated interactions 
using object orientated design techniques, each 
business process object being designed to provide 
one or more services in response to an event; and, 



35 
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b. determining the risk of at least some of the 
business process objects not providing a service 
in response to an event. 

The present invention overcomes this by determining a 
separate risk for at least some of the business process 
objects which define the business. This allows the risk to 
be determined on a far more accurate basis by basing the risk 
on the possibility of a portion of the business failing to 
operate correctly rather than on the basis of an abstract 
equation which does not reflect .the actual operation of the 
business in any way. 

In the situation in which the business is designed in 
accordance with the first aspect of the invention the method 
of determining the risk preferably further comprises: 
15 a - assigning a risk value to each event response 

action of each state of the business process 
object, the risk value being representative of the 
risk of the event response action not being 
performed; 

20 *>• defining a relationship between the event response 

actions of the states; and, 

c. determining a risk value representing the risk of 
a business process object not providing a service, 
the risk value being determined on the basis of 

25 the risk values associated with each event 

response action and the relationship therebetween. 
The risks can therefore be related to specific events 
within the business and by combining the risk values for each 
event the risk value of a business process object not 

30 performing a desired service can be determined. This allows 
the model to take into account the fact that failure to 
provide one event response action could lead to failure of 
other related event response actions. Alternatively, the 
risk value could be assigned directly to the business process 

35 object. 
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The method of assigning a risk value to a given event 
response action comprises determining the likelihood that the 
respective service implementation cannot be completed. 

Typically the method further comprises assessing the 
5 risk of a failure in a business by: 

a. determining the risk of each business process 
object not providing a service in response to an 
event, for all events and all business process 
objects; 

10' b. determining a relationship between the business 

process - ob j ect s ; and, 
c. determining a risk based on the risk associated 
with each business process object and the 
relationship therebetween. ■ 
15 This allows a single value to be determined for the 

entire business. Whilst this value does not relate to any 
one event in particular, the components of the event can be 
determined by consideration of the business process object 
and statechart structure of the business. The single values 
20 have a useful implication of the overall function of the 
business. In particular, should this value increase 
significantly this would suggest that some area of the 
business is having trouble implementing the services 
currently allocated to it. This would therefore allow the 
25 business to be redesigned with a lower risk state, thereby 
improving the efficiency and operation of the business. 

In accordance with a third aspect of the present 
invention, we provide a method of designing or optimizing an 
Internet based business system, the business system being 
30 formed from a number of service providers, the method 
comprising defining the business system as a number of 
business process objects and their interactions using object 
orientated design techniques, each business process object 
representing a respective service provider and being designed 
35 to provide one or more services in response to an event. 

The present invention therefore provides a malleable 
business design which allows the designed business system to 
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be highly flexible so that the system provides a highly 
reconf igurable set-up where services are out-sourced, co- 
sourced, in-sourced and/or shared as appropriate. This 
reflects the dynamics of the ever changing business 
5 relationships which typically occur for Internet based 
businesses. This system therefore allows alterations in the 
industry to be readily integrated in to the business model, 
whilst improvements in the business model can readily be 
propagated into the working business system. 

10 The method preferably uses a number of business process 

objects to represent service consumers which interact with 
the business process objects which represent the service 
providers to. receive desired services. However, customers 
need not be represented in this way and can instead, for 

15 example, be represented as events for the request of services 
within the business model. 

Typically the method is implemented using the methods 
of the first and second aspects of the invention. Thus the 
risk assessment of the second aspect of the invention can 

20 also be applied to the Internet based business model. 

Typically at least some of the service implementations 
are implemented using Enterprise Java Beans . This allows the 
business model to define the service implementations in 
sufficient detail for many services to be automated in 

25 accordance with the operation set out in the model. 

An example of processes according to the present 
invention will now be described with reference to the 
accompanying drawings, in which: - 

30 Appendix Drawings 

Figure A is a schematic representation of a business 
process object; 

Figure B is a schematic diagram of a request for 
approval of a loan from a loan application business process 
35 object; 

Figure C is a schematic diagram of a non-core 
capability; and, 
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Figure D is a schematic diagram of the inheritance of 
services from a first business process object by a second 
business process object which is a specialisation of the 
first. 

5 

Description Drawings 

Figure 1 is a schematic representation of three 
complementary views of object orientated analysis; 

Figure 2A is a schematic diagram of a service request 
10 to a customer business process object; 

Figure 2B is a schematic diagram of a customer business 
process object; 

Figure 2C is a schematic diagram of the delegation of 
business responsibilities between business process objects; 
15 Figure 2D is a schematic diagram representing the 

distribution of business responsibilities to people and 
systems within a business process object; 

Figure 2E is a schematic diagram of a business process 
object which has been modified to encapsulate people and 
20 system capabilities ; 

Figure 2F is schematic diagram of a modification of the 
business process objection in Figure 2D in which additional 
automation has been included; 

Figure 2G is a schematic diagram of the provision of 
25 mortgage services using a mortgage account and customer 
business process objects; 

Figure 3A is a schematic diagram of a business; 

Figure 3B is a schematic diagram of a statechart of the 
business shown in Figure 3A; 
30 Figure 3C is an example of the business process object 

representation of the business shown in Figure 3A; 

Figure 3D is an example of a modified version of the 
business process object representation of Figure 3C; 

Figure 4A is a service implementation diagram for the 
35 "open an account" business service; 

Figure 4B is a simplified statechart for the account 
business process object of Figure 4A; 
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Figure 4C is an example of a graphical user interface 
representation of the states of Figure 4B; 

Figure 4D is a schematic diagram of the aggregate 
responsibility distribution for "opening an account"; 
5 Figure 4E is an example of a graphical user interface 

of states modified in accordance with Figure 4D; 

Figure 4F is a schematic diagram representing the 
organization reverse engineering of a business; 

Figure 4G is a schematic diagram representing the 
10 process design of a business; 

Figure 4H is a schematic diagram representing the 
creation of a business design; 

Figure 5 shows an object hierarchy diagram showing the 
proposed relationships between the FX/IR trade and credit 
15 derivatives ; 

Figure 6 shows a modified version of the object 
hierarchy diagram of Figure 5 including the modifications 
that are required to the credit derivative and FX/IR trade 
designs; 

20 Figure 7 shows the statechart diagram for the FX/IR 

trade administration business process object; ' 

Figure 8 is an object hierarchy diagram showing a 

modified relationship between the FX/IR trade object and a 

credit derivative object; 
25 Figure 9 is a modified version of the statechart of 

Figure 7; 

Figure 10 is a second level statechart sub-diagram of 
the trade management state shown in Figure 9; 

Figure 11 is a third level statechart sub-diagram of the 
30 management cash flows state shown in Figure 10; 

Figure 12 shows a modified version of the object 
hierarchy diagram shown in Figure 8; 

Figure 13 shows a list representing the relationship 
between the statechart diagrams of different levels; . 
35 Figure 14 is a poor capabilities diagram floor trade 

administration in the credit derivatives business process 
object; 
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Figure 15 is a second level core capabilities sub- 
diagram showing the core capabilities of the trade management 
core capability of Figure 14; 

Figure 16 is a third level core capabilities diagram 
5 showing the core capabilities of the cash flow management 
core capability of Figure 15; 

Figure 17 is a fourth level core capabilities sub- 
diagram of a management subsequent fixings core capability of 
Figure 16; 

10 Figure 18 is a service implementation diagram for the 

surface rate fix of Figure 17; 

Figure 19 shows an example of the firmament framework 
of the present invention; 

Figure 20 shows the met a -model of the method of the 
15 present invention; 

Figure 21A is a representation of the core capabilities 
of Risk Management within a client bank; 

Figure 21B is a representation of an object hierarchy 
associated with the core capabilities of Figure 21A; 
20 Figure 22 is a modified version of the meta-model of 

Figure 20, modified to provide operational risk assessment 
and management reporting; and, 

Figure 23 is an example of the core capabilities of Risk 
Management and Capital Allocation. 

25 

The main concepts which are used to design or modify a 
business using the present invention are set out in Appendix 
A, below. The main forms of diagram usjed by the invention 
are briefly explained in Appendix B. 

30 
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Firmament Framework 

The approach of the present invention is based on the 
identification and the design of business process objects 
(business design) . This then needs to be followed by a 
5 well -planned implementation and roll -out of business process 
objects (change management) . This process which is known as 
the Firmament Framework is an iterative procedure in that 
once a section of the business has been analyzed in a given 
way, the resulting model is compared to previously determined 

10 models so that further adaptions can be made. 

An outline of this process is shown in Figure 1 and this 
shows how the three main techniques which are used, namely 
the business process object modeling, the behavior modeling 
using statecharts and the implementations are interrelated. 

15 Accordingly, the modification of the model derived by one 
technique may effect the model determined by another 
technique. Once this effect has been included in the model, 
the first model may then require further modification. 

The main concepts of the invention will now be 

20 described, followed by examples of the operation of the 
invention. 

Business Design 

Only carefully designed business process objects should 
25 be used when attempting to build an effective business. In 
general, good designs provide a stable base for future 
improvements, whereas poor designs are the root of a rapid 
deterioration . 

A very important concept is that of object designs which 
3 0 serve as useful blueprints for construction of business 
process objects. New objects can be built rapidly from the 
design whilst preserving the consistency at all times. When 
business process objects need to be changed the comple--? ty of 
that exercise may be greatly reduced by the fact that many of 
35 them share the same design. 
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Clearly defined object designs and their enactments, the 
business process objects, are major assets of an effective 
business. 

Object designs (and therefore the business process 
5 objects based on these designs) encapsulate system 
capabilities and people competencies and the interactions of 
the two. 

An object design is a complete and unique (encapsulated) 
business asset which defines a set of closely related 

10 business capabilities or services. 

For example, the Mortgage Account object design shown 
in Figure D (and discussed in the Appendix A) encompasses, 
all the business rules and system supports needed to provide 
a mortgage as well as all the people competencies required 

15 for example to authorize a payment break. Corrpetencies are 
carried out by roles, such as a Mortgage Account Manager. 

When designing effective businesses, it is necessary to 
avoid having People, Team, Person, Account Manager as 
identities separate from business process objects. Instead 

20 peoples roles should be defined in object designs and 
contained in enactments thereof, i.e. in business process 
objects. 

Similarly, the system details (databases, networks, 
computers...) should be avoided at early stages of business 

25 design as the associated technology is not stable and changes 
almost overnight. 

The most striking example is that of the Customer object 
design which is effectively the group of related services 
which allow a business to interact with customers. This 

3 0 business asset does not represent the person on the street, 
or a client from an external business but, instead, 
encapsulates all capabilities available to the organization 
to deal with the person on the street, or with the business 
client . 

35 It should be noted that all in this context is not 

extended to advocate 'big 1 objects. Business process objects 
may, by their own Business nature, have numerous 



SUBSTITUTE SHEET (RULE 26) 



WO 00/46705 



PCT/GB00/00297 



19 

responsibilities but more often than not many of these can be 
delegated to other, better equipped business objects. 

A Customer object design will include much more than 
customer data on the database and the services to display or 
5 change this data. It will include the organization's ability 
to communicate with the customer, (e.g. using telephone 
equipment and the people well trained in telephone manners) , 
as well as the ability to deal with customer requirements. 
It should be noted however that a Customer business process 
10 object should not be considered solely as the "Customer 
Liaison Department" . In an effective organization there will 
be very few centralized departments. 

A Customer business process object will deal with one 
or more customers and, typically, there will be more than one 
15 Customer object in the business. 

In order to be provided with a service from a business 
process object, it is necessary to request it. 

Figure 2A is a schematic diagram of a service request 
to a. Customer business process object, the service being 
20 to" inform the Customer". 

The assumption is that the Customer object design 
defines a business service of the same name. This definition 
generally includes performance requirements, such a minimum 
return on an investment or a minimum level of customer 
25 satisfaction. The customer business process object shown in 
Figure 2B includes an indication of the business services 
which are defined by the customer object design. This is 
important as it allows business designers to maximize the re- 
use of assets. 

30 In use, the business process objects co-operate in order 

to meet their individual responsibilities. Thus as shown in 
Figure 2C, a Mortgage Account business process object 
delegates the responsibility of performing a service (in this 
case informing the customer) to an alternative object (in 

35 this case the customer object) which is able to provide the 
service. The definitions accompanying the design should also 
show the intended delegation of performance targets. 
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Change Management 

With people and systems aspects firmly encapsulated in 
object designs, once the business responsibilities become 
clear it is possible to design people roles and the 
5 supporting system. 

First of all, when there is no obvious other business 
process object to delegate to, the responsible business 
process object distributes this responsibility internally, to 
the encapsulated people cpmpetencies and system capabilities. 
10 Thus if there is no other business process object which 

obviously provides a given service, then the business process 
object will be adapted to provide the service itself. 

An example of this is shown in Figure 2D. In this case 
the service to be provided is informing the customer, which 
15 is achieved by displaying the customer details and then 
telephoning the customer. As no other business process 
objects provides these services, then the customer business 
process object is adapted as required. In this particular 
adaptation the customer object uses system capabilities 
20 (denoted by s_) to display the customer details and personnel 
competencies (denoted by p_) to telephone the customer . 

It will be realized that the capabilities to display 
Customer details and to telephone the Customer are internal 
(private) to the Customer business process object and are not 
25 normally accessed from other business objects. However, 
Customer will not become a bottleneck in a well -designed 
organization. Business process objects ait usually 
replicated and distributed, i.e. there will be a number of 
Customer objects providing the necessary services across the 
30 business. 

A modified version of the Customer object of Figure 2B 
is shown in Figure 2E. In this case, the Customer object has 
been modified to include an indication of the display and 
telephone business services which are defined by the customer 
35 object design. 

The separation of business designs from the 
implementation details means that the responsibility 
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distribution can be continuously improved without affecting 
the core business. Thus in the example shown in Figure, 2F, 
the service capabilities of the customer object are improved 
such that the system not only displays the customer details 
5 but also automatically dials the Customer's telephone number 
(denoted by s_dial) thereby reducing the work required by the 
personnel competencies. 

When the business design and the responsibility 
distribution are stabilized and agreed, it is possible to 
10 start the role design and system design. 

After consultations with 'Human Resources', the role 
design could be as shown in Table 1. 



TABLE 1 



20 



Role Design 


Roles (shading indicates changes since the 
previous design) 


Competencies 






Mortgage 

Account 

Manager 


Loan 
Officer 


approve the 
Loan 






new 


existing 












authorize 
overdraft 




•new.-:,.-:, || H|| 


N.A. 


N.A. 



Taking this into account, a first draft of a system 
25 design for the provision of mortgage services would be as 
shown in Figure 2G. 

Outline Example 

A general example of the method of the invention will 
30 now be discussed. It will be appreciated that whilst the 
term business is used throughout the description, the present 
invention could be applied either to an entire business, or 
to a discrete portion of the business, such as a subsidiary 
company only. 

35 The first stage is to define how the business interacts 

with the external world. This can typically be achieved by 
considering and providing a high level definition of the 
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business capabilities which need to be developed. 

For each of these capabilities, which are implemented 
as the provision of services, a short but precise statement 
of what is required, but not how it might be implemented, can 
5 be produced. Thus, for example, in the case of opening a new 
bank account the statement could be as follows: 

"A new account will be created subject to checking the 
customer and checking the application. The customer will 
10 be informed about the outcome." 

Once all the capabilities have been defined, the 
business can be considered as a single business process 
object which interacts with the external world by providing 

15 the defined services in response to events which define a 
request for such a service. 

Figure 3 A shows an example in which the business i? a 
bank. In this case, the bank business process object 1 must 
be able to respond to events which are indicated generally by 

20 the arrows 2, and examples of which include a request to open 
an account, and a request to provide security for cash 
deliveries/collection. The responses are in the form of the 
provision of services which are indicated by the arrows 3 
such as the opening of an account and the provision of 

25 security. 

Once the business has been defined in these terms, it 
is then possible to derive a statechart representing the 
operation of the business process object. The statechart may 
be obtained from a database of predetermined statecharts, or 

30 alternatively may be generated by consideration of the events 
and services associated with the business process object, as 
will be explained in more detail below. 

In some circumstances the previous development of 
businesses will result in the generation of business process 

35 objects which are suitable for modeling the business project 
object of the current example. In this case, the statechart 
can be determined from the statechart of the previously 
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designed business process object. 

In order to determine whether a predetermined business 
process object is suitable for use as the business process 
object under consideration, the two objects, the events to 
5 which the objects respond and the services provided are 
compared. In general the predetermined business process 
object is deemed to be suitable if it: 

• provides all required services, or 

• can be extended without distorting the core 
10 behavior of the object, or 

• a new object design can be derived by specializing 
the existing one, or 

• a new object design can be derived by generalizing 
the existing one, 

15 The statechart of the business process object therefore 

may require modification which will be explained in more 
detail below. 

In order to generate a new statechart, it is necessary 
to divide the business process object into a number of 
20 states. This is achieved by separating the events associated 
with the business process object into a number of related 
groups, with each group being associated with a respective 
state of the business. 

Thus, in the example of the business being a bank, the 
25 various transactions dealing with customer accounts could 

f orm -one-group "6f~ related events, whereas the provision of 

security to the bank will form a separate set of events. 
Accordingly, in this case, the statechart would be of the 
form shown in Figure 3B, in which an account state 4 and a 
30 security state 5 are provided. 

Once the states have been defined, event response 
actions can also be defined for each state as shown by the 
arrows 6. The event response actions represent the action 
that is needed by the respective state in order to ensure 
35 that the required service is provided. 

Each state in this statechart itself corresponds to a 
respective business process object, with the event response 
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actions representing the services provided by the respective 
business process object. 

Each business process object can therefore be considered 
in more detail. Again, this may be achieved by comparing the 
5 business process object to a number of predetermined business 
process objects, or by generating a statechart for the 
business process object by considering the events to which 
the business process object must react and the services which 
the business process object will provide. 

10 It will be appreciated that this process can then be 

repeated to form a hierarchical structure of statecharts 
which define the operation of the business. Each statechart 
therefore provides details of how a respective business 
process object will operate to provide the required services. 

15 Furthermore, each state of the statechart itself represents 
a business process object such that the statechart itself 
represents how a number of more narrowly defined business 
process objects must interact to enable a more broadly 
defined business process object to be implemented. 

20 The procedure of the present invention therefore enables 

further and further levels of statecharts to be generated 
with each successive statechart providing further details of 
a more narrowly defined area of the business than the 
previous statechart. This process is generally continued 

25 until the states of the statechart define event response 
actions in sufficient detail to allow them to be implemented. 

The implementation of event response actions is achieved 
by defining service implementations which are a series of 
procedures required to ensure the desired event response 

30 action is performed following the occurrence of the 
respective trigger event. The event response actions, 
therefore represent the procedures that must be carried out 
to enable the business process object to implement the 
service which corresponds to the respective event response 

35 action. 

The service implementations may therefore comprise a 
wide range of different procedures from a series of 
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instructions to personnel within the firm, to a computer 
program designed to automatically respond to a request for 
information. 

Furthermore, the service implementations can be 
5 generated at any stage to aid the modification and creation 
of other portions of the business model. Thus, for example, 
the process of defining a service implementation for an event 
response action may highlight that the state which is 
generating the event response action needs to be defined in 

10 more detail. 

Again, where the event response action is siinply a copy 
of a service which is already implemented by another business 
process object, then the service implementation can be copied 
from the service implementation of the other business process 

15 object, making any modifications that are required. 

If however no previous similar service has been 
implemented, then it is necessary to determine the service 
implementation diagrams from a consideration of how the 
service is to be provided. 

20 Returning to the exanple of the statechart shown in 

Figure 3B, the statechart includes an account state which in 
turn corresponds to an account business process object which 
is configured to handle account enquiries. 

This situation is shown in Figure 3C which represents 

25 the business process objects, namely an account object 8 and 
a security object 9, so far defined. At this stage, these 
represent the core capabilities of the bank 1. 

In this example, the account business process object can 
be defined in more detail by considering previously defined 

30 business process objects. Assuming that the database 
contains only the object designs which are mentioned in the 
appendix, then the most similar business process object is 
the Mortgage Account object design which handles nr^tgage 
accounts. 

35 As mortgages are a specialized type of account, the 

account business process object can be considered to be a 
generalization of the Mortgage Account object design. 
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However, in contrast to the Mortgage object design, the 
Account object design requires a further capability, namely 
the capability to process applications. Accordingly, the 
object design, when generalized is modified to include a 
5 processing applications capability. 

This can be achieved by direct consideration of, and 
modification of the statechart of the Mortgage Account 
business process object. 

However, in order . to modify the statechart, the 

10 procedures that are required to process applications must 
first be determined. In this example, this is achieved by 
determining the service implementation that is required for 
the account business process object to process applications. 
In this case, the service implementation is produced in the 

15 form of a diagram showing the interactions that are required 
between the business process object and the customer and 
application business process objects, a suitable example of 
which is shown in Figure 4A. 

In this diagram the instructions are developed in a 

20 clockwise manner. The sequence of events is therefore as 
follows : 

1) Receive an "open" request at the Account Object. 

2) The Account Object requests a check of the 
Customer via the Customer Object. 

25 3) The Account Object then checks the application via 

the Application Object. 
4) After receiving confirmation that the application 
is acceptable, the Account Object opens the 
account . 

30 5) The Account Object instructs the Customer Object 

to inform the Customer that the account is open. 
The documentation work arising from this diagram 
involves : 

• Account object design 

35 • Application object design 

• Definition of the service to check the Customer 
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Accordingly, it is realized from this that it is 
necessary to modify the model of the bank to include an 
application business process object 10 and a customer 
business process object 11, as shown in Figure 3D. Unlike 
5 the security business process object 9 which does not 
interact with the account business process object 8, the 
application and customer business process objects 10,11 
interact with the account business process object 8, as shown 
by the arrows 12. 

10 It will be realized that this information could also 

have been obtained by considering a core capabilities diagram 
of a bank business process object. This would have shown 
that the bank business process object would require customer 
and application business process object in addition to 

15 security and account business process object. Accordingly, 
several different approaches can be used in. conjunction or 
independently to obtain the same result. 

Furthermore, the service implementation diagram of 
Figure 4A highlights that the requirement to process 

2 0 additional accounts results in the account business process 
object having a number of states not inherently present in 
the mortgage account business process object. Accordingly, 
the statechart of the account business process object would 
require the addition of the states shown in Figure 4B. 

25 This allows the operation of the Account object to be 

monitored and modified as required. (It should be noted that 
Figure 4B does not show events which stimulate state 
transitions. Also, beware that some events do not cause state 
changes . ) 

30 An example of how this statechart information may be 

represented on a graphical user interface (GUI) is shown in 
Figure 4C. Even if the GUI subsequently needs to change, it 
is essential to maintain traceability with the statechart. 
Consideration of the statechart representation on the 

35 GUI also gives rise to at least 3 new 'use cases': 

• Suspending an Account 

• Re -opening an Account 
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• Closing an Account 

There are also a number of questions, such as which 
services should be provided for suspended accounts. As a 
result of this consideration of the service implementation 
5 diagrams and the statecharts, further modifications can 
therefore be made. 

The next step is to distribute responsibilities to 
people and systems for all 'leaf business services, i.e. 
those which are not further elaborated on other diagrams. 
10 This can be done by designing an aggregate responsibility 
distribution for the whole service implementation diagram as 
shown in Figure 4D. 

The accompanying definitions should also show the 
intended distribution of performance targets. The GUI 
15 development might include the modifications shown in Figure 
4E, based on the people responsibilities identified in Figure 
4D. 

To re -iterate, even if the GUI subsequently needs to 
change, it is essential to maintain traceability with the 
20 design. 

When the responsibility distribution is fully agreed 
between the business analysts, the 'human resources 1 and the 
systems specialists, the work can commence on the detailed 
design and implementation of people competencies and system 
25 support. 

Ultimately, the resulting Clients 1 business process 
objects will be not only compatible with the ' structure 1 of 
their business - they will effectively become the business 
(•Object Orientated business 1 or "00 1 Business for short). 
30 The difference between an 00 business and conventional 
businesses is best illustrated by describing the types . of 
services the invention can provide: 

(i) organization reverse -engineering - where a 

1 road-map 1 of the existing business functions 
35 is created, as shown in Figure 4F; 

(ii) process design - cutting right across functional 

barriers thus making the business process 
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driven, as shown in Figure 4G; 
(iii) business design - creating a flexible- 

to-change business based on re-usable 
building blocks (business process objects) 
5 thus creating an '00 business', as shown in 

Figure 4H. 

Implementation 

The present invention will generally be implemented on 
10 a suitable processing system. The advantage of using a 
processing system is that the data representing the various 
hierarchical levels of the business model can be linked so 
that the various levels can be easily viewed. 

Thus, for example, each core capabilities diagram which 
15 shows the business objects and their respective interactions 
would also be linked to statechart diagrams so that selecting 
a given business process object results in the statechart of 
that business process object being displayed. Similarly, 
once a statechart is displayed, any stkte within that 
20 statechart can be selected and the appropriate business 
process object and its associated core capabilities can be 
displayed. 

In order to achieve such a . system, it is therefore 
necessary to have the statechart, the core capabilities and 
25 the service implementations of the business set out in 
suitable look-up tables in a memory. Each look-up table can 
then include links to other look-up tables as appropriate. 

In particular, this has the advantage that when 
predetermined business process objects are used, the tables 
30 can be stored in a database and the information contained 
therein can easily be incorporated into the current model by 
including a reference to a table within the database. 

By providing the suitably adapted processing system, 
this allows the statechart, the core capabilities and the 
35 service implementations to be presented as diagrams which can 
therefore be readily understood. 

Furthermore, by using an appropriate processing system 
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any design changes implemented in one section of the business 
model can automatically be integrated to other sections of 
the business model, as appropriate. Furthermore, any changes 
at a more detailed level will automatically propagate through 
5 to higher level definition of the business. 

Figure 20 shows a meta-model which sets out the steps 
involved in providing software implementation of the method 
of the present invention. This highlights the steps needed 
to perform the method so as to define and optimise a 
10 business. 

Design Focusing 

From the above, it is apparent that as the business is 
developed an iterative process occurs in which the 

15 consideration of various aspects of the business results in 
the modification of other aspects. If the business were 
considered as a whole, this would be prohibitive to the 
successful modification of the business.. However, by 
studying smaller business process objects which relate to a 

20 specific portion of the business, this allows the business to 
developed in a modular manner, with each part of the business 
being defined in sufficient detail to allow it to be 
implemented. 

A particular advantage of this is that when the business 
25 model is considered, it is possible to examine the business 
model at different levels of detail which are appropriate to 
the observer. This therefore allows people to focus on the 
business at a level which is relevant to them. 

Thus, in the present example, an employee in the tax 
30 section in a sub-branch in one country will not have any 
interest in how the business as a whole operates. In 
contrast to this, the director of the company will be very 
interested in how the business operates but will not 
necessarily be interested in how tax is calculated in a sub- 
35 branch in a particular country. 
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Po lyznorphi sxn 

A further advantage of the technique of the present 
invention arises from the object orientated feature of 
polymorphism. Polymorphism means that similar business 
5 process objects may have to respond to similar events so as 
to provide similar responses. However the manner in which 
the business process object is implemented may vary 
significantly depending on the circumstances in which it is 
used. 

10 Thus, in the present example of a bank, typically there 

will be provided a business process object for calculating 
tax. However, in the situation of an International 
corporation, the actual tax calculations that have to be 
performed will vary from country to county. Thus, for 

15 example, the specific calculation of tax in the UK will be 
different to that in the US and again to that in .Japan. 

However, the general operation of the tax business 
process object will be standard in that the tax business 
process object will respond to a calculate tax event to 

20 calculate the required tax.. Thus, as the tax business 
process object will function in the same manner regardless of 
the country or size of bank branch in which it is 
implemented, it can be used throughout the world. 

However, the specific calculation of the tax, will vary 

25 depending on the branch location. Accordingly, the specific 
service implementation of the tax business process object 
will be different for branches in different countries to 
reflect the differences in the calculations required to 
determine the tax payable. So although the tax business 

30 process object reacts to the same event and provides the same 
end response, the actual implementation is vastly different. 

In this case, the statechart of the tax business process 
object itself will also be substantially similar throughout 
the globe, as the basic events in the procedure of tax 

35 calculation are substantially the same. Thus the general 
steps are to receive tax request events, to process the tax 
due and provide an indication of the tax due. 
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However, when this statechart is considered in more 
depth, the specific implementation will vary between each 
country. As the implementation is itself defined by more 
detailed statechart s further down the hierarchy, these 
5 statecharts may well include variations between the different 
countries. 

Thus for example, for the calculation of the tax in 
Japan it may require only a single person working to 
calculate the tax on a. set of given transactions. In 

10 contrast to this, in alternative countries such as the UK an 
entire team of people using a conqplicated computer software 
system will be required. 

These differences will be reflected with detailed 
statecharts and service implementations for the tax business 

15 process object. 

Thus at a higher level, which for example would be 
considered by a company director, the tax business process 
object appears identical, even though the implementation is 
different. Accordingly the tax business process objects are 

20 a polymorphism. 

A second example of a polymorphic relationship is shown 
in Figures 21A and 2 IB. Figure 21A represents the core 
capabilities required by a risk management department in a 
bank and this is intended to provide certain uniformity of 

25 implementation (not only for regulatory reasons) across the 
Bank. 

Figure 2 IB is an object hierarchy diagram which shows 
that the uniformity can be preserved even when extending the 
generic capabilities of Risk Management for different 
30 business lines, e.g. Risk Management in Debt and Capital 
Markets (DCM) has, additionally, the capability called 
"spread risk". Furthermore, and equally importantly, Risk 
management in Fixed Income (FI) also has a "spread risk" 
capability, but the implementation may be different to that 
35 in DCM. This is why polymorphism is sometimes referred to as 
the "customizable uniformity" . 

An additional advantage of polymorphism is in increasing 
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productivity i.e. business dynamics. For example, as soon as 
Risk Management, Risk Management in DCM and Risk Management 
in FI agree upon the core capabilities required for Risk 
Management, the latter two can start implementing their 
5 spread risk capabilities. Note that DCM and FI do not have to 
agree how (although it would make sense if they did not use 
overloaded name for completely unrelated different 
•capabilities) the spread risk capabilities are implemented. 
Furthermore , DCM and FI have in common, at least, the 
10 statechart defined by the generic Risk Management. 
Conversely, although they may share even the part of the 
statechart which deals with "spread risk", when that 
capability is required DCM will respond by invoking the 
Sybase/C++ implementation of an algorithm STP34Zx whereas in 
15 FI, a dedicated person use a pencil and paper to perform a 
manual calculation based on departmental method MYOWN46. 

Accordingly, by using a polymorphism this allows the 
business to be defined in a far more efficient manner. In 
particular, this allows the business to function in the same 
2 0 manner globally at the scale of the tax business process 
object but in the specific implementation which could be 
calculated on a country by country basis, there are 
variations which are required for the tax business process 
object to function in a suitable manner. 

25 

Risk Calculation 

An additional application of the present invention is 
in the calculation of the operational risk of a business. 

The present invention calculates an overall risk by 

30 determining a separate risk for the provision of each service 
by a respective business process object. The risks can 
therefore be evaluated for business process objects at 
various levels of the hierarchical structure of the h-^iness 
and the results propagated through to higher levels. 

35 In general,, it is easiest to start at the most detailed 

level which looks at the implementation of specific services 
within the business. Thus, for a group of business objects, 
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a risk may be assigned to each business process object 
capability on the basis of the risk of the respective service 
not being provided in response to the respective event. 

By evaluating this for each business process object 
5 capability, and considering the interaction between the 
different business process objects, it is possible to 
determine from this how failure to perform the given 
interaction will effect the remainder of the business. 

Thus, in a group of closely related business process 

10 objects, it may be that failure of one business process 
object to provide a service may in turn mean that other 
business process objects will also fail. This fundermental 
connection between the business process objects is inherent 
in the model derived by the present invention. 

15 For example, in the case of the core capabilities of the 

Integrated Risk Management and Capital Allocation structure 
shown in Figure 23, if Group Finance fails to adequately 
provide the service "capture trade data in GI n then it may 
als.o fail to provide other services it has contracted-by- 

20 design, such as: 

a. provide financial data for audit (to External 
Auditor, Tax Advisor) 

b. provide financial data (to Regulators) 

c. determine how much capital there is (to Calculate 
25 ROC and Allocate capital) 

The present invention therefore provides a technique 
which uses a step-by-step analysis of failures of certain 
portions of the business to allow a risk value to be 

30 evaluated and to determine how a failure may effect the 
overall operation of the business. 

In the present invention, as each higher level business 
process object is defined in terms of a number of 
interconnected lower level business process objects, the risk 

35 of a business process object failing to provide a service can 
be calculated as a non-linear sum of the risks associated 
with interactions of the respective lower level business 



SUBSTITUTE SHEET (RULE 26) 



WO 00/46705 



PCT/GB00/00297 



process objects. 

By performing this non- linear sum at each level of the 
hierarchy, a value representing the overall operational risk 
of the entire business can be evaluated. 
5 This particular value may not have a meaning in the 

sense that it does not provide an indication of where the 
business will go wrong. However, it does provide an 
indication of the current operating risk of the business. If 
this is too high, or at some stage during the operation of 
10 the business shows an increase, this allows people to see 
that improvements need to be made to the business. 

In a system designed according to the present invention, 
a high operational risk can be examined in great detail by 
looking at the different levels of the business model to 
15 determine if a weak point exists which contributes 
significantly to the overall risk. 

Thus, for example, the managing director may only look 
at the overall operation of the business in terms of its core 
capabilities. From this, the operational risk, associated 
20 with the business, and with each of the core capabilities can 
be determined. This may identify to the director that one of 
the core capabilities has an exceptionally high operational 
risk. 

The director can then request that the person in charge 
25 of that particular core capability identify why this risk is 
so high and then operate to reduce the risk. The head of 
the indicated section can in turn look at the statechart 
and/or a more detailed business object representation of the 
respective core capability. This allows him to determine 
30 which respective business process object out of all the 
business process objects defining the core capability has the 
highest risk. 

By following this procedure through, it allows a 
business process object deep within the structure of the firm 
35 which has an unduly highly risk to be identified, thereby 
allowing the risk to be addressed so that it can be reduced 
which in turn improves the overall operating efficiency of 
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the business. 

The present invention therefore allows people to focus 
on the risk involved in the business at a level which is 
relevant to them. Thus, an employee in the tax section of 
5 the branch of a bank will not have any interest in the risk 
value for the business as a whole but will be interested in 
the risk involved in providing the required tax calculations. 
In contrast to this, the director of the company will be very 
interested the risk associated with the entire business but 
10 will be less interested in the risk involved in specific 
operations, unless this unduly effects the overall risk 
value, in which case it becomes more relevant. 

However, because the present invention uses software 
which operates to model all the systems within interrelated 
15 charts, each member of the company can use the same model to 
determine the risk value for the company at a level of 
interest to them. 

In addition to this, the present invention can be 
adapted to implement a management report system showing 
20 possible domino effects arising from a single failure point. 
In this case, the software used to model the business is 
adapted to automatically generate the reports for a selected 
business process object. The reports may be generated on 
request, or alternatively, the software may be adapted to 
25 detect when a failure occurs (using the data linking 
described below) and then generate a report highlighting the 
effects of this failure. 

In the current example, the Bank's process Calculate ROC 
and Allocate Capital and external regulators and External 
30 Auditor, Tax Advisors are immediate candidates for failure. 
Exanples of suitable reports that could be generated are 
• shown in Tables 2 and 3. 

Figure 22 shows a meta-model which sets out the method 
of the present invention when adapted to provide both risk 
35 calculation and management reporting. 
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Table 2 f Continued 
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Table 3 
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Table 3 (Continued) 
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Data Linking 

A further major benefit of the present invention is that 
data may be fed back from the actual operation of the 
business into the business model. Thus, documents may be 
5 associated with particular business process objects within 
the model. 

An example of this is for a customer business process 
object to be linked to data indicating the number of 
customers using the business. This allows any member of the 

10 organization to access the model and obtain information 
regarding the number of customers the bank currently has. In 
addition to this because there will be a number of different 
customer business process objects within the entire bank, 
this allows the values to readily be broken down for 

15 individual business process objects in the bank or for the 
bank as a whole. 

By regularly monitoring this data, this allows 
efficiency of the business to be determined. Thus for 
example, the expenditure of the company will be available 

20 from the model as well as indications of the profit. This 
allows the operation of the business to be monitored so that 
improvements to the business can be implemented. 

This illustrates an important point that business models 
not only need to be summarized and reported (e.g. for 

25 duplications and gaps) , but that they can be used to 
introduce a structure into management reporting. 

In the present invention, business processes and service 
requests are supported by forms. These can be ActiveX 
documents which allow a "physical" link between a process 

30 model and the day-to-day operation of that process to be 
established. In this the invention becomes the control 
center of, say, a dynamic Bank which designs process 
improvements , measure the KPI's and, based on the 
measurements, proposes further improvements . 

35 
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Further Uses 

The present invention can also be advantageously used 
when considering business systems operating on communication 
network systems, such as the Internet. In this example, the 
5 business system could be considered as a network of service- 
to- service providers with each service provider providing a 
number of related services. In this case, each service 
provider could be defined as a respective business process 
object in the design of the business. 

10 In addition to this, additional business process objects 

can be provided which represent consumers of the services. 
These may themselves provide additional services or simply be 
general public customers. 

From the above described implementation of the 

15 invention, it will be realised that consideration of the 
statecharts of the various business process objects will 
allow the Internet based service providers to be easily 
implemented. Furthermore, the service implementations of the 
service providers can often be defined as Enterprise Java 

20 Beans which allows services to be readily provided. 

This system will also allow private and public services 
to be defined with the non-public services only being 
available to a limited number of service providers and/or 
consumers, or alternatively the services may be internal 

25 within a service provider itself. 

This type of malleable business design allows the 
designed business system to be highly flexible so that the 
system provides a highly reconf igurable set-up where services 
are out-sourced, co-sourced, in-sourced and/or shared as 

30 appropriate. This reflects the dynamics of the ever changing 
business relationships which typically occur for Internet 
based businesses. This system therefore allows alterations 
in the industry to be readily integrated in to the business 
model, whilst improvements in the business model can readily 

35 be propagated into the working business system. 

Examples of Internet business -to-business services are 
the credit risk services that banks are likely to want to 
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make available to their clients. This will tend to be along 
the lines of the trades the client has, what their current 
value is, what the current collateral hold against them is, 
what netting arrangements are in place and what limits are 
5 placed on the trades. Accordingly, as will be appreciated by 
a person skilled in the art this allows clients to obtain 
information directly from the bank in accordance with the 
defined business model. 

10 Specific Example 

A specific example of the . implementation of the 
invention to determine a method of operating a business will 
now be described. 

In the following example, the intention is to build a 
15 capability to administer credit derivatives throughout their 
life cycle. It is necessary to generate a complete process 
definition along with associated user documentation, as well 
as to automate a large part of the process. In this example, 
it will be assumed that a business process object for 
*20 administering effects and IR trades is already stored in a 
database, along with an associated state chart diagram which 
is shown in Figure 7 . 

Firstly, it is necessary to carry out a high level 
analysis of - the service requirements needed to administer 
25 credit derivatives. This involves analyzing the requirements 
to administer credit derivatives and determining therefrom 
the actions that are required for the associated credit 
derivatives business process object to carry out. The 
requirements of the credit derivatives object are then 
30 compared to a database of alternative business process 
objects and it is revealed that there is a high level of 
similarity to the FX/IR trades business process object. The 
main difference between these business process objects is 
that additional features are required in the credit 
35 derivative business process object. 

Accordingly, the credit derivative business process 
object (hereinafter referred to as the credit derivative 
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object) is assumed to be a specialization of the FX/IR trade 
business process object (hereinafter referred to as the FX/IR 
trade object) , as shown in Figure 5A. 

The use of a predetermined business process object will 
5 allow the clients to benefit from uniform handling of FX/IR 
and credit derivative trades as well as being able to employ 
the high level of automation that is currently present in the 
FX/IR trade object without having to generate the system from 
scratch. 

10 However, in this example, the potential clients of the 

credit derivative products decide that they also want the 
rate fixing of the credit derivative to be automated. 
Accordingly, in addition to extending the FX/IR trade object 
to handle "credit events" as required by credit derivatives, 

15 it is also necessary, to adapt the FX/IR trade object to allow 
the software automation of "rate fixing" . This is shown in 
Figure 6. It will of course be appreciated that other 
requirements may be placed on the credit derivative business 
object. 

20 The first stage is to access the statechart of the FX/IR 

trade object which is shown in Figure 7. This statechart 
setB out the different states of the business process object 
with event response actions indicating services provided by 
the individual states. 
25 In order to proceed further, it is necessary to analyze 

the business events that are required to provide for the 
handling of credit derivatives. This includes determining 
not only whether any new states need to be added to the 
statechart shown in Figure 7, but also to determine whether 
30 it is necessary to modify any of the existing states. 

In this case, in order to handle credit events, the 
following modifications are required: 



New State: 

35 • Assessing Impact of Credit Event (AICE) 

New Event in state Trade Management: 

• credit event (causes transition to AICE) 
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New Events in state AICE: 

• further credit event (causes no state change) 

• ignore event (causes transition back to Trade 
Management ) 

5 • cancel (causes transition to Trade Management) 

• exercise (causes transition to Trade Management) 

• handle event which permanently changes deal 
(causes transition to Trade Management) 

• restructure in. response to credit event (causes 
IQ transition to Amending/Restructuring) 

• expires worthless (causes transition to Ended) 

• full cancellation with no payments due (causes 
transition to Ended) . 

New Events in state Amending/Restructuring: 
15 • credit event (causes transition to AICE) 

Analysis of these goals shows that whilst the initial 
plan was to derive credit derivatives from the FX/IR object 
there are certain indications in this structure which must 

20 be considered. The most notable of which is that any future 
changes to the PX/IR trade object would be directly inherited 
by the credit derivatives object. It can be readily foreseen 
that certain changes to the FX/IR trade object would not be 
desirable in the case of the credit derivatives object. 

25 Accordingly, a new more sophisticated relationship 

between the two business process objects is proposed, as 
shown in the object hierarchy diagram shown in Figure 8. In 
this case, a more general trade object is generated, which at 
the current moment is simply a direct copy of the FX/IR trade 

30 object. The FX/IR trade object then becomes a specialization 
of the trade object without any changes. The credit 
derivatives object is similarly a specialization of the trade 
object. 

Effectively, the services provided by the trade object 
35 are specialized to administer credit derivatives, with some 
changes and extensions where necessary. In the case of the 
FX/IR trade object no changes are needed. It should be noted 
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that initialization can redistribute people and systems 
responsibilities for provision of inherited services. For 
rate fixing, however, both manual and automatic services are 
required. 

5 Returning to the statechart diagram shown in Figure 7 

which now applies to the trade business process object, it is 
now necessary to make the modifications outlined above to 
ensure that the credit derivatives object can handle credit 
events as well as allow for the automated rate fixing. 
l0 The first modification is to add the additional state 

of accessing impact of a credit event (the AICE state) and 
then link this to the current states by a number of 
appropriate event response actions. This results in the 
statechart shown in Figure 9. 
15 Next it is necessary to modify the existing states of 

the statechart to allow for the automated rate fixing 
capability. In order to implement the changes that are 
required to trade management state, it is necessary to derive 
a more detailed representation of the state to determine 
20 where the changes must be incorporated. 

Accordingly, a second level statechart is determined for 
the credit derivatives trade management object (it will be 
appreciated that each state of the statechart is in itself an 
object which is an instance of the credit derivatives 
25 business process object) . This second level statechart is 
shown as a diagram in Figure 10 and is derived either from an 
analysis of the capabilities of the trade management object, 
or preferably by considering the second level of the 
statechart for the trade management object of the more 
30 general trade object. 

An analysis of the second level statechart sub-diagram 
shown in Figure 10 reveals that the rate fixing capability is 
a capability of the managing cash flows object. Accordingly, 
a third level statechart is produced of the managing cash 
35 flows object, as shown in Figure 11. 

In this case it can be seen that the subsequent fixings 
due event response action will need to be performed in a 



SUBSTITUTE SHEET (RULE 26) 



WO 00/46705 



PCT/GB00/00297 



47 

different way to if the system is to provide automatic rate 
fixing as opposed to using a manual system. This represents 
a polymorphism of subsequent fixings due event response 
action. 

5 In view of the relationship shown in Figure 8, the rate 

fixing related services can be generalized to the general 
trade object if desired. Such an action will then allow the 
FX/IR trade object and the trade object to inherit the 
automation of rate fixing.. This is a useful side effect of 

10 the present invention in that modifications made to existing 
business process objects are propagated to similar business 
process objects thereby increasing the efficiency of the 
entire business. 

This improved approach to automated rate fixing is 

15 represented in a modified object hierarchy diagram as shown 
in Figure 12 . As shown the automated rate fixing due is now 
a feature of the trade business process object and is 
therefore inherited by the FX/IR trade ^business process 
ob j ect . / 

20 The next stage in the process is to apply traceability 

between high level business design and the software 
implementation level. This allows software from the trade 
business process object to be used in the credit derivatives 
business process object. 

25 In this example, the refinement of the fixing business 

sub-process, taken from the business diagram for trade 
administration is demonstrated. This refinement process also 
establishes a close relationship between core capabilities 
diagrams and state chart diagrams. Figure 13 shows a list 

30 outlining the relationship between the statechart diagrams of 
different levels. 

Figure 14 is a high level core capabilities diagram for 
trade administration which shows core business activities 
which are defined in more detail in subsequent diagrams. The 

35 starting point here is Trade Administration which is an 
identified function of the Market Area introduced by earlier 
workshops. It is a front/middle/back office capability for 
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handling trade definition and manipulation. 

Figure 14 shows that the main business activities (core 
capabilities) for Trade Administration are: Booking, 
Amending, Trade Management, Assessing Impact Of Credit Event, 
5 Valuation and Analysis. It further shows the interaction 
between these capabilities and other system areas (whether 
business or infrastructure) - for example the interaction 
with Confirmations. 

At this level the service requests are indications of 
10 business intent rather than of software implementation. The 
subsequent refinement of the core capabilities listed above 
will start to show the exact adoption of these services by 
business objects. This is particularly true for interaction 
between Trade Administration as a whole and Counterparty, 
15 Confirmations, Financial Control incl . Accounting and others. 

Each of the core capabilities of Trade Administration 
(those objects surrounded by the "box") can be seen as a 
state for Statechart diagram, for Credit Derivatives 
Administration which is shown in Figure 5. For example, the 
20 Booking core capability maps to the Booking state on the 
Statechart, Trade Management core capability to the Trade 
Management state, and so on. The only exception is Valuation 
and Analysis, which exists as a (major) event on the 
statechart. In general, states "handle" a number of events, 
25 this particular event can occur in every state so the 
transitions to/ from Valuation and Analysis would have 
cluttered the diagram without adding much value. 

Unlike Service Implementation diagrams, for overview 
purposes and completeness it is acceptable to show requests 
30 between two objects neither of which are a core capabilities 
(e.g. provide Treasury/LIBOR market data from Fixing 
Maintenance to Market Data Management) . 

For the purposes of this document, Trade Management will 
be the core capability / state concentrated on from this 
35 point. The business responsibility of Trade Management is to 
manage the trade - whether this is looking at em individual 
trade cash flow or the trade as a whole. In this sense, the 
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Trade Management core capability also represents a state 
within the trade lifecycle: the trade has been defined and 
dealt through the Booking process; it is now being managed. 
That, in turn, requires additional capabilities. 
5 The core capabilities identified are: Cash flow 

Management ( a grouping of capabilities that apply to 
individual cash flows ) , Manage Full Cancellation, Option 
Exercise, and Manage Payments Due. These core capabilities 
can also be modeled as event managers on the Trade Management 
10 sub-states of the second level statechart shown in Figure 10. 

Figure 15 is * a diagram of the second level core 
capabilities of the trade management core capabilities of 
Figure 14 . This shows more precisely how service requests to 

15 and from the Trade Management object (e.g. interaction with 
• the "external" capability to manage Counterparty ) have now 
been delegated .. to these core capabilities. For example, 
Payments and Payments Netting Management provides a service 
to Manage Payments Due. 

20 The next step, as set out in Figure 13 is to examine the 

cash flow management core capability in more detail. In this 
case the sub-processes involved are manage cash flow payments 
due, manage manual first fixing due and manage subsequent 
fixings. A diagram of the core capabilities of cash flow 

25 management is shown in Figure 16 which represents the third 
level core capabilities. Further to this diagram, it is now 
necessary to examine the manage subsequent fixings capability 
further and accordingly, the fourth level core capabilities 
are determined as shown in Figure 17. This is a core 

30 capabilities, diagram of the manage subsequent fixings 
capability. 

It will be appreciated that in the case in which the 
trade business process object has been defined in sufficient 
detail, these core capabilities diagrams can be obtained 
35 directly from the core capabilities diagrams of the business 
process objects. However, if no such core capabilities 
diagrams have been derived, then the diagrams must be 
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generated from scratch by a consideration of the services 
provided by each of the capabilities and the way in which the 
capabilities interact. 

The sub-processes involved in Manage Subsequent Fixings 
5 are: Calculate Fixing Price/Rate, Calculate Settlement 
Amount, Apply Rate/Price Fixing. In all of these core 
capabilities the actual implementation is not relevant as 
yet, although it will be shown at a lower level primarily 
through Service Implementation diagrams or occasionally 

10 through further Core Capabilities diagrams. 

Each of the sub-processes has been represented as an 
object, although in the "final" implementation these may 
become services on a cash flow. On the one hand it is 
important to capture and reflect the business process for 

15 doing something rather than trying to make implementation 
decisions too soon. On the other hand, the core capabilities 
(groups of services) are typical units of reuse rather than 
individual services. Of course, it is perfectly legitimate to 
consider rate fix to be a service of Cash flow Management. 

20 Shown in Figure 17, the rate fix is a service provided 

by the apply rate/price fixing object. Accordingly, the 
apply rate/price fixing object is the controlling object 
which manipulates and drives the calculate fixing price/rate 
and the calculate settlement amount objects. 

25 The implies certain mutual responsibilities between 

Calculate Fixing Price/Rate, Calculate Settlement Amount and 
Apply Fixing. The service rate fix, corresponds to the 
business event subsequent fixing due shown in Figure 10. 

Figure 18 shows the Service Implementation for the 

30 service rate fix indicating the typical sequence of events 
and interaction with other objects required to complete the 
service. This demonstrates how Apply Rate/Price Fixing 
delegates its responsibilities to Calculate Fixing 
Price/Rate, Calculate Settlement Amount, Amount, Rate and 

35 Confirmations to provide the service rate fix. The service is 
meant to be implemented in Java and triggered by subsequent 
fixing due event, see the Statechart diagram. 
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10 



indirect dependencies on other objects should be shown 
on separate service implementation diagrams. The closer we 
get to software implementation, the more important it is to 
understand that a service request to an object (for example 
update to Amount) must be met by services of the same name. 
In this case object Amount should have a service called 
update . 

Business events defined above will have their contracts 
defined in more detail on the associated Firmament Framework 
form, an example of which is shown in Figure 19. 



Guard: 

Initially the guard was "is fixing due", however, the 
current underlying assumption is that this process will be 
15 automated through the use of a Fixing Timer. This has lead to 
the redundancy of this guard. The current guard is a Boolean 
expression to check if the trade has already been fixed (e.g. 
manually, so we do not want the rate to be overwritten) . 

2 0 Event : 

The transition event in the Statechart diagram is 
subsequent fixing due, (see Figure 11: Statechart diagram 
for Managing Cashflows)., where the Event Type is Time Event. 
At this stage, the interfaces to (Fixing) Timer are undefined 
25 so there are no services available. Future design on the 
Timer should allow completion of the form, specifying the 
service generating event. 



Action: 

30 The Action invoked is the rate fix service - which maps 

to the business service supplied by the object Apply 
Rate/Price Fixing. 

The key requirement is that states, events and response 
35 actions on the Statechart diagram must be provided by 
business objects within the design. 
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Appendix A 

Object Design 

An object design is a blueprint for the provision and 
rapid replication of a group of related business services, 
5 Good designs enable efficiency, re-use and consistency. 
Initially they result from a systematic analysis of business 
'requirements'. In a mature effective business, new 
requirements do not always necessitate fundamentally new 
designs, as many of the existing designs can be re-used with 
10 or without improvements, thus allowing a collection of 
predetermined business process objects to be developed and 
re-used during subsequent business analysis. 

Business Process Object 
15 A business process object is an enactment (instance) of 

a business object design. Typically, an object design will 

have a number of enactments, each of which is capable of 

conducting responsibilities specified in the design. 

A well designed assembly of communicating business 
20 process objects is a business process object in its own 

right, usually called 'business (sub) process 1 . For example, 

Savings Account management. 

A business process object is represented schematically 

in Figure A. In this example the business process object is 
25 a particular branch of a bank which is implemented using a 

branch object design. 

Encapsulation 

The term refers to the fact that the business services 
3 0 of an object design should be complete and void of 
duplication, and be void of features which are better suited 
to other object designs. 

The data and implementation details of a business 
process object, although potentially visible, are not 
35 intended to be directly accessed by other objects. This is 
to allow for the propagation of changes, to promote re-use, 
reduce the maintenance cost and minimize the risk of 
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improvements . There are varying levels of this information 
hiding' which allows for selective access to details for 
those 'who need to know 1 (so called public, private and 
protected business services, as set out in more detail 
5 below) . 

An example of 'information hiding 1 is in the case of a 
staff working roster which is essential for the successful 
operation of the Branch. Typically, however it is not 
advertised to the customers and would therefore be hidden 

10 . from a customer object . Similarly, the deployment of Branch 
security services is not meant to be widely understood. 

An example of a situation in which features of a 
business are better suited to alternative business process 
objects is for the business process object for operation of 

15 the Mail -room in a Bank. The mail-room manages internal and 
external mail and nothing else. As a result, features such 
as the catering facilities should be managed by another 
business process object. 

An example of completeness and 'information hiding 1 is 

20 in the case of a payroll which generates pay slips and 
initiates payments. In this case most of the necessary 
detailed implementation (e.g. calculation of National 
Insurance/Tax deductions, Pension contributions, returns to 
the Inland Revenue) are not normally published to the Bank 

25 staff who only receive summary information. 

Business Services 

A business service is a clearly defined, non- redundant , 
sharply focused ability of a business process object to 

30 provide capabilities. If a capability is provided to other 
objects the capability is known as a "public" service whereas 
if the capability is used to assist the provision of other 
capabilities of the same object it is known as a "prot -:ted" 
or "private" service. 

35 A business service may be either centralized (static) 

or distributed as well as primary or acquired (as defined in 
more detail below) . 
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Service Request / Delegation 

Public (but not private or protected) business services 
of a business process object can be requested by other 
objects. This is done by issuing a service request named 
5 after the existing service. An example of this is shown in 
Figure B in which a request for approval of a loan is made to 
a loan application service. 

Centralized Service 

10 A single business service which relates to all 

enactments of an object design is known as a centralized 
service. Such centralized services are rare but do occur. 
One example, would be the production of a weekly report 
calculating the Total number of successful customer 

15 engagements across a network of Bank Branches. 

A Centralized Attribute is a special case of a 
Centralized Service, for example the Total number of Branches 
in the Branch network • 

20 Distributed Service 

A business service which relates to a single business 
process object is known as a business service. Typically, it 
operates on the data encapsulated in the owning object and, 
perhaps, on some centralized (static) data, but not directly 

25 on the data of another object. 

For example, the responsibility to obtain customer 
signature on a Loan Application, or to verify customer ID is 
distributed to all branches. Nevertheless, the customer data 
is managed centrally, 

30 A Distributed Attribute is a special case of Distributed 

Service. This is information which is managed by and is 
responsibility of an individual business process object, for 
example a Bank Branch Diary. 

35 Primary Service / Core Capability 

A core capability is an encapsulated business service. 
Thus it is an encapsulated auxiliary business process object 
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('attribute') together with all its associated business, 
capabilities. For example, for a Branch service to accept 
cash and credit a customer's account also utilizes services 
of an Account object. 
5 Primary services of an object design can be brand new 

features, or passed down ('inherited 1 ) from other object 
designs. Alternatively primary services can be features 
which are specialized versions of passed-down business 
services, see below. 

10 

Acquired Service / Non-core Capability 

Some business process objects out-source one or many of 
their responsibilities to the named external (i.e. not 
encapsulated) objects and are therefore known as non-core 
15 capabilities. 

An example of a non-core capability is shown in Figure 
C which shows stationary being obtained for a branch account 
object from an external supplier. 

20 Private Service 

An auxiliary or transient service which is visible to 
other business process objects but is not intended to be used 
by them is a private service. For example, Security 
arrangements are vital for operation of each Branch but, 
25 typically, branches do not offer them as a service to other 
business units of the Bank. 

Protected Service 

A business service intended to be used only by the 
30 owning business process object or specializations thereof is 
a protected service- For example, Security arrangements for 
A.T.M. cash can be specialized to cover cash deposits but 
probably not to cover Catering cash. 

In absence of object designs specializations, protected 
35 services are no more accessible than private services. 



SUBSTITUTE SHEET (RULE 26) 



WO 00/46705 



PCT/GB00/00297 



56 

Public Service 

A stable and permanent business service designed to be 
used by other business process objects is a public service. 
Typically, public services are implemented through a number 
5 of fine grain private or protected services. For example, 
Telephone Banking currently offers a relatively narrow range 
of services to the customers but requires a much wider people 
and systems infrastructure. 

10 Design Specialization / Inheritance 

A technique for creating more detailed object designs 
from the existing, more general designs ('a base class 1 ) is 
known as specialization. This technique promotes re-use, 
consistency and integrity of object designs. For example, 
15 the service to provide financial advice for a new product is 
a specialization of the general capability to provide 
financial guidance to the customers. 

Figure D shows the situation in which the public and 
protected services of an account object are inherited by a 
20 more specialized mortgage account service. This inheritance 
can be with or without changes. 

Specialization is the foremost business design technique 
to manage .the ever-changing market conditions. It should be 
also seen as extending or adding value to the general object 
25 designs without affecting the common parts. Note that 
specialization can re-distribute people and systems 
responsibilities for provision of passed-down services. 

In the present invention Object Hierarchy diagrams are 
used to represent design specializations. 

30 

Design Generalization / Inheritance 

Generalization is a technique for creating more general 
object designs from the existing, more detailed designs. This 
technique promotes re-use, consistency and integrity. For 
35 example, the service to provide total financial guidance to 
the customers is a generalization of the more narrow 
capability to provide financial advice for a new product. 
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Another view is that this is abstraction, i.e. identification 
of core capabilities. 

In the example of Figure D, some services of the 
mortgage account object can be generalized and used by the 
5 more general account object. 

Object Hierarchy diagrams, which are explained in more 
detail below, are also used for design generalizations.. 

Specialization of Internal Capabilities 

10 The specialization of internal capabilities enables 

internal re-use, with or without improvements, of services 
which were passed down from a more general design. The point 
here is that services inherited this way are not being made 
directly available to other business process objects (even 

15 though they may have been accessible from the enactments of 
the more general design) . For example, a policy concerning 
security over cash is passed down from a general policy 
object but would have to be specialized if it were to be used 
by an object dealing with a particular type of risk (e.g. 

20 A..T.M. cash) . 

Specialization of Public Services 

The specialization of public services enables the 
provision of additional public services by re-using, with or 
25 without improvements, the public services passed down from 
a more general design. For example, 'Mortgage Lending may be 
specialized to support first -time -buyer mortgage lending. 

Polymorphism 

3 0 Different business process objects may respond 

differently to the same service request, yet the design of 
the object guarantees some level of consistency. This is 
known as polymorphism. For example, greeting customers can 
be consistent, yet customers 1 specific circumstances (e.g. a 

35 recent death in the family) should be taken into account. 

Polymorphic objects may appear identical even when they 
do not have a single line of code in common. Thus giving both 
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the business clients and local service providers a 
considerable advantage: the former need not worry about the 
detail, the latter have the clarity of objectives without too 
many constraints. 
5 For solutions vendors, the key to 'customer intimacy 1 

whilst preserving consistency. 

Very importantly, business process objects in the same 
object hierarchy have polymorphically consistent statecharts. 

10 Inputs of a Service 

The totality of information required for the provision 
of a business service is known as the inputs of a service. 
For example, completed application form is required for the 
service to open a new account . 

15 

Service Pre-condition 

Service pre-conditions must be satisfied before a 
business service can be provided. For example, signing (by 
the customer) of an Application form. The act of signing 
20 changes the state of the Application object. 

Service Deliverable 

A deliverable service is output resulting from provision 
of a service. For example, a new A.T.M. card is generated 
25 when a new account is opened. 

Service Outcome 

In addition to providing the deliverables, provision of 
a service may change the range of services offered to the 
30 customer. This is known as the service outcome. For example, 
Account usage is restricted when the customer goes "missing" . 

Expressiveness 

Expressiveness refers to keeping options open, for 
35 example, technical details of a new financial product. 

Business people can drag&drop business objects and 
create products (without programmers involvement) . 
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Appendix B 

Diagram Types Overview 

The following section provides details of the types of 
5 diagrams used in the methods of the present invention. 

Core Capabilities Diagrams 

Core capabilities diagrams are intended to ■ give 
confidence that all external responsibilities of the business 

10 (sub) process undergoing improvements are being met. Core 
capabilities (see section Design Generalization / Inheritance 
) encapsulate a group of related services, for example, all 
event response actions which may be required in a process 
state. They also show mutual responsibilities between core 

15 capabilities, these are expressed as service requests (arrows 
pointing to service providers) . At this stage of design we 
also identify major business events. 

Statechart Diagrams 

20 Statechart diagrams partition the business event space 

into manageable sub-spaces, where event response actions are 
services provided by business objects. Statechart s give 
engineering rigeur to business designs and sufficient 
precision to object hierarchies by enforcing behaviourial 

25 aspects of objects. They may also provide the first insight 
into Graphical User Interfaces as described further below. 

Service Implementation Diagrams 

Service Implementation diagrams give engineering rigeur 
30 to the design of individual business object services where 
necesS ary. They promote delegation, encapsulation and 
information hiding (an example of such a diagram is shown in 
Figure 4A) . 

35 Business Improvement Environment Diagrams 

Business Improvement Environment diagrams define the 
scope of process improvements. They also identify external 
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and internal clients of the process, and the mutual 
responsibilities. It is important to note that the system 
users participate in the process undergoing improvements, 
whereas client processes and their users are "outside" (as 
5 explained in section Business Design) . 

Object Hierarchy diagrams 

.Object Hierarchy diagrams are used to highlight the 
requirements of inheritance and polymorphism and effectively 

10 represent the relationship between different levels of a 
business object designs. Inheritance is treating new 
situations as extensions of known situations. Polymorphism 
means agreeing what not how. It is important to note that 
polymorphism is an analysis / design issue and not just a 

15 programming language feature. It can reduce dependencies by 
an order of magnitude . 

Ptech Distributed Class Models 

Ptech Distributed Class Models capture; design decisions 
20 regarding the distribution of object services within the 
target computing environment, e.g. between clients and the 
server . 

The focus is on Core Capabilities diagrams, Statechart 
diagrams and Service Implementation diagrams. 

25 The above diagram types form three complementary views 

of the business: Object Interactions, Object Hierarchy and 
Behaviour, and Distributed Object Design and Implementation, 
as described in the Section entitled Firmament Framework and 
as shown in Figure 1. 

30 Each of the three views is important and no single one 

is sufficient. They are meant to be applied iteratively until 
the design is complete and consistent. Thus the present 
invention removes the usual ambiguity between top-down and 
bottom-up approaches to business design and change 

35 management. 
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CLAIMS 

1. A method of designing or optimizing a business, the 
method comprising defining the business as a number of 

5 business process objects and their interactions using object 
orientated design techniques, each business process object 
being designed to provide one or more services in response to 
an event. 

2. A method according to claim 1, defining the business as 
10 a number of interacting statecharts, each statechart 

representing a number of states of business processes or sub- 
processes . 

3 . A method according to claim 1 or claim 2 , wherein the 
method comprises defining the business as a number of 

15 statecharts, each statechart representing a number of states 
within the business, the states being interconnected by 
events and corresponding event response actions, each state 
corresponding to a respective business process object and 
each event response action corresponding to a service 

20 provided by the respective business process object in 
response to an event. 

4. A method according to claim 3, wherein the method 
further comprises determining the service implementation of 
at least some of the event response actions, the service 

25 implementation defining . the procedures required for 
implementing the respective event response action. 

5. A method according to claim 4, wherein the method 
further comprises defining at least some of the business 
process objects as respective statecharts so as to generate 

30 a hierarchical structure of statecharts. 

6. A method according to claim 5, wherein the method of 
determining a statechart of a business process object 
comprises the steps of: 

a. comparing the business process object to a number 
35 of predetermined business process objects; 

b. determining if one of the predetermined business 
process objects can be related to the business 
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process object by an object-oriented process; and, 
either: 

i. using a predetermined statechart of a 
predetermined business process object that is 

5 related to the business process object; or, 

ii. generating a new statechart. 

7 . A method according to claim 6 , wherein the predetermined 
business process object is a generalisation or a 
specialisation of the business process object. 
10 8. A method according to claim 6, wherein the method of 
generating a new statechart comprises: 

a. determining events to which the business process 
object must respond; 

b. dividing the events into sets of related events, 
15 each set of related events being associated with 

a respective state of the business; 

c. for each event, defining one or more event 
response actions for providing the required 
services . 

2 0 9. A method according to claim 8, wherein the method 
further comprises incorporating the generated statechart and 
the associated business process objects into the model of the 
business. 

10. A method according to claim 6 or claim 7, wherein the 
25 method of using the predetermined statechart comprises: 

a. comparing the services provided by the 
predetermined business process object with the 
services to be provided by the business process 
object; and, 

30 b. if necessary, modifying the selected statechart by 

performing at least one of the following steps: 

i. adding in one or more new states, and 
interconnecting the new states to existing 
states using appropriate event response 

35 actions so as to provide the required 

services; or, 

ii. modifying the event response actions of 
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existing states to represent changes in the 
services to be provided by the business 
process object. 

11. A method according to claim 10 , wherein the step of 
5 modifying the event response actions of an existing state 

comprise modifying the service implementation of the event 
response action such that the state provides the required 
services. 

12. A method according to claim 11, wherein if the service 
10 implementation of the event response action cannot be 

modified, the method further comprises: 

(1) considering the business process object of the state to 
be modified; 

(2) determining a second level statechart of the business 
15 process object of the state to be modified; 

(3) determining the states of the second level statechart 
diagram which are to be modified; 

(4) for any states for which the service implementation 
cannot be altered to provide the required services, 

20 repeating steps (1) , (2) and (3) to generate the nth 

level statechart diagram for which the service 
implementation of the state can be altered to provide 
the required services; and, 

(5) modifying the service implementation of the event 
25 response actions of the states of the nth level 

statechart such that the modified statechart represents 
the services provided by the respective business process 
object. 

13. A method according to any of claims 10 to 12, wherein 
30 the method further comprises: 

a. considering the modified statechart and the 
predetermined statechart; 

b. considering the effect of inheritance on the 
operation of the business process object as 

35 defined by the modified statechart and the 

predetermined business process object; and, 

c. adapting the relationship between the business 



fil IRRTm fTE SHEET (RULE 26) 



WO 00/46705 



PCT/GBOO/00297 



64 

process object and the predetermined business 
process object as required. 

14. A method according to any of claims 4 to 13, wherein the 
service implementation defines one or more algorithms 

5 configured to perform at least a portion of the respective 
event response action. 

15. A method according to any of claims 4 to 14, wherein the 
service implementation defines one or more sets of 
instructions indicating the tasks to be performed in order to 

10 perform at least a portion of the respective event response 
action. 

16. A method according to any of claims 4 to 15, wherein the 
method further comprises determining the service 
implementation diagrams for a given event response action of 

15 a state, the method comprising: 

a. comparing the business process object associated 
with the state to a predetermined business process 
object; f 

b. determining a service implementation for an event 
2 0 response action of the state of the predetermined 

business process object; and, 

c. modifying the service implementation to allow the 
required event response action to be implemented. 

17. A method according to any of the preceding claims, 
25- wherein the method further comprises determining the core 

capabilities of a state of the business, the core 
capabilities representing the business process objects and 
their respective interactions required for the state to be 
implemented . 

30 18. A method according to claim 17, wherein the method 
further comprises: 

a. comparing the core capabilities with a number of 
predetermined core capabilities for different 
business states corresponding to the predetermined 

35 business process objects; and, 

b. modifying the core capabilities and the 
statecharts in accordance with the predetermined 
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core capabilities. 

19. A method according to claim 18, when dependent on claim 
16, wherein the service implementation is selected from the 
service implementation of one of the predetermined core 

5 capabilities. 

20. A method according to any of the preceding claims, 
wherein the method further comprises generating statechart 
diagrams representing the states, the event response actions 
and the event for a given statechart. 

10 21. A method according to any of the preceding claims, 
wherein the method further comprises generating core 
capabilities diagrams showing the business process objects 
and their respective interactions which represent the core 
capabilities of any state of the business. 

15 22. A method according to any of the preceding claims, the 
object orientated processes including the use of inheritance . 
23 . A method according to any of the preceding claims, the 
object orientated processes including the use of 
polymorphi sm . 

20 24. A method of presenting business data relating to a 
business according to at least claim 20 and claim 21, wherein 
the method further comprises associating business data with 
the statecharts and/or the core capabilities, thereby 
allowing the data to be viewed on the appropriate diagram. 

25 25. A method of risk assessment within a business, the 
method comprising the steps of: 

a. defining the business as a number of business 
process objects and their associated interactions 
using object orientated design techniques, each 

30 business process object being designed to provide 

one or more services in response to an event; and, 

b. determining the risk of at least: some of the 
business process objects not providing a service 
in response to an event. 

35 26. A method according to claim 25, wherein the business is 
defined in accordance with any of claims 3 to 23, the method 
of determining the risk further comprising: 
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a. assigning a risk value to each event response 
action of each state of the business process 
object, the risk value being representative of the 
risk of the event response action not being 

5 performed; 

b. defining a relationship between the event response 
actions of the states; and, 

c. determining a risk value representing the risk of 
a business process object not providing a service, 

10 the risk value being determined on the basis of 

the risk values associated with each event 
response action and the relationship there 
between. 

27. A method according to claim 26, wherein the method of 
15 assigning a risk value to a given event response action 

comprises determining the likelihood that the respective 
service implementation cannot be completed. 

28. A method according to claim 26 or claim 27 , wherein the 
method further comprises assessing the risk of a failure in 

20 a business by: 

a. • determining the risk of each business process 
object not providing a service in response to an 
event, for all events and all business process 
ob j ects ; 

25 b. determining a relationship between the business 

process objects; and, 
c. determining a risk based on the risk associated 
with each business process object and the 
relationship there between. 
30 29. A method of designing or optimizing an Internet based 
business system, the business system being formed from a 
number of service providers, the method comprising defining 
the business system as a number of business process objects 
and their interactions using object orientated design 
35 techniques, each business process object representing a 
respective service provider and being designed to provide one 
or more services in response to an event. 
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30. A method according to claim 29, wherein the method 
further comprises defining a number of business process 
objects representing service consumers which interact with 
the business process objects representing the service 

5 providers to receive desired services. 

31. A method according to claim 29 or claim 30 , wherein the 
method is implemented in accordance with the method of any of 
claims 2 to 28. 

32. A method according to claim 31, when dependent on at 
10 " Ifeast claim 3, wherein at least some of the service 

implementations are implemented using Enterprise Java Beans. 
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